New `forge-loop brainstorm` subcommand wires the existing Brainstormer
(issue #122) and GhClient (issue #83/#123) into an operator-facing CLI.

Behavior:
* No flags → discover ProductVision, run Brainstormer, dump the
  BrainstormReport as YAML to stdout. Zero GitHub calls.
* --apply → file proposed epics first (labels: axis:<name> + epic),
  then file proposed tickets (labels: axis:<name> + loop:ready) with
  `Parent: #<epic-number>` cross-link bodies threading the returned
  epic numbers.
* Missing/invalid ProductVision → exit 2 with a clear stderr line and
  no partial state.
* Partial failure during --apply → exit 1; successful issues are
  reported on stdout (with their numbers), failures with title +
  error are reported on stderr.
* --apply is opt-in; default never writes.

Why opt-in matters: without a hard default-dry-run, a stray
`forge-loop brainstorm` would file epics + tickets against whatever
repo `LOOP_GH_REPO` points at — which is exactly the failure mode
the spec is defending against.

Supporting change to gh_client (#83 framework): adds `create_issue`
to the GhClient Protocol + GithubkitClient + MockGhClient. The
protocol previously covered only reads + label edits; the brainstorm
CLI is the first writer call site, so the method ships alongside.
MockGhClient gets `create_issue_responses` / `next_issue_number` /
`raise_on_create_titles` knobs so tests can pre-stage epic numbers
and inject per-title failure.

Tests (tests/test_cli_brainstorm.py): full acceptance matrix from
the issue — dry-run YAML shape, epics-filed-first ordering with
parent cross-link, epic+ticket label contracts, missing/invalid
vision exits, partial-failure exit-1 with per-title reporting,
empty-report no-op, and an adversarial "default never writes" test
that catches a future regression flipping --apply on by default.

Also registers `brainstorm` in the existing test_cli.py help-list
smoke test so future help-regressions surface early.